Web servers are computers configured to respond to requests from other computers for web pages. A web server may be part of a global computer network, part of an intranet, or part of another network. Various communication protocols may be used, both at lower network levels (TCP/IP, SPX, and so on) and at higher levels (hypertext transfer protocol, file transfer protocol, and so on) in combination with various web page formats (HTML, XML, and so on). Many web sites are primarily linked pages of hypertext and images, but web pages increasingly contain database inquiries, email addresses, and other information that calls for more than the mere presentation of previously specified text and graphics. Accordingly, various attempts are being made to extend the functionality of web servers.
One approach extends web servers to make them capable of running "servlets." Servlets are focused code components (sometimes called "modules" or "plug-ins") which can be added to an existing server with relatively little effort. Each servlet preferably has a well-defined task, such as servicing database requests, sending email, translating IP addresses into domain names, uploading files, posting news group messages, and so forth. Java servlets are portable between platforms by virtue of being implemented in Java bytecodes (JAVA is a mark of Sun Microsystems, Inc.). Indeed, "servlet" is often (but not always) used as a synonym for "Java servlet."
Regardless of the terminology used, many of the security considerations that apply to Java servlets apply to other executable tasks as well. Security is a particular concern when an executable task may be loaded by a server and then run as a separate thread or process to extend the server's functionality by performing a specific job. In addition to Java servlets, such executable tasks include NetWare Loadable Modules and other modules or components implemented in native code, as well as native or Java applications initiated by (or closely coordinated with) the server.
Server security is a concern for several reasons. A server typically has broader access rights than the clients it serves, and the server often runs on behalf of different users at different times. Precautions must be taken to protect the confidential information of the various users. In many systems, servlets run by the server also have broad rights because a thread or other process created by a server process normally has the same rights as the server process. Thus, servlets and similar tasks must either be trusted to the same extent as the server that runs them, or else precautions must be taken to prevent security breaches by such tasks.
The fact that servlets may be loaded dynamically from a source outside the server makes security breaches an even greater concern. The origins and history and behavior of the remote servlet are not necessarily known to the local server administrator. Even if certain origins or behavior are stated for the remote task, such statements might be untrue. Unless suitable precautions are taken, for instance, a malevolent servlet could present itself as a legitimate database update server and then make illicit changes to the database. Or the server might do the job it was called on to do, such as sending and delivering email messages, but do illicit work as well, such as gathering user passwords and periodically mailing them to an unauthorized location.
One general approach taken to improve servlet security imposes a "sandbox" model. All servlets loaded from the server's disk are trusted, and thus have the same security rights as the server itself. By contrast, all servlets loaded from a remote location are untrusted. Untrusted servlets are invoked by a separate instance of the server's dispatcher and they run in a group of untrusted threads which are kept apart from the trusted threads. This means, among other things, that untrusted servlets cannot access the program data and instructions of trusted servlets, so an untrusted servlet cannot gain unauthorized access to system resources by infecting or taking over a trusted servlet. This approach is called a "sandbox model" because one set of servlets gets to play in the sandbox (the server's space) with broad rights or even all possible rights, while other servlets are excluded from the sandbox in the sense that they have very limited security rights.
In addition to the sandbox model, Access Control Lists are used in some systems. An Access Control List ("ACL") is a data structure associated with a system resource and used to control access to the resource. ACLs assume that an authentication method is available to identify users, and they also assume the use of user or group permissions information that reflects the possible ACL settings.
When a user logs onto a system that uses ACLs, the system first uses a login name to identify the user and then uses an authentication means such as a password, biometric scan, ID card, or other means to determine whether the stated identity is correct. When an authenticated user tries to access a resource such as a file, database, email account, printer, or other resource, the system compares the rights of the authenticated user with the rights required to perform the requested access and then allows or denies access accordingly.
In one system using a sandbox model, the server and the trusted servlets which run as threads of the server are either not subject to authentication or else are authenticated to a powerful user such as "root" or "admin." The untrusted servlets run as threads of a separate dispatch process, which is authenticated by the server as a user having relatively high priority for execution but very restricted security rights. In one system, there is a server-wide ACL and separate ACLs can be specified to control access to a specific file, directory, or servlet. Using ACLs to control access to servlets is one way to reduce or prevent unauthorized changes to trusted servlets.
Another general approach taken to improve servlet security requires the servlet to present the server with authenticating credentials before the server will let the servlet run. Credentials may be based on shared symmetric keys, on a public key infrastructure, on digital signatures, on certificates issued by one or more Certification Authorities, or on certificates issued according to a so-called web of trust; in many cases, credentials are based on some combination of these items.
One of the many possible examples of servlet security based on credentials is the sun.security.TrustDecider method is TrustedFor( ), which checks to see whether an entity named in a certificate chain is trusted for a specified purpose. The certificate chain normally includes the servlet certificate, the certificate for the servlet's Certification Authority, the certificate for that Authority's Certification Authority, and so on up to a root Certification Authority's self-signed certificate. Specified purposes may include authenticating a peer through a secured channel or authenticating a specific code signer, for instance.
Unfortunately, both the sandbox model and the use of credentials have serious drawbacks when applied to servlet security. The sandbox model is not very flexible. Although servlets loaded from remote locations must generally be treated with caution, some remote locations, and some servlets, are more trustworthy than others. But a strict sandbox approach makes all remotely loaded servlets equally untrusted. Likewise, the sandbox model violates the principle of least privilege ("each process gets only those privileges its needs to do its legitimate work") by giving every locally loaded servlet full server rights. Even if the locally loaded servers are not malevolent, programming errors may cause problems that would not have occurred if the servlet had only those rights it actually needed to do its job.
Drawbacks of the credential model become apparent when one considers the need to revoke a credential. Revocation may be needed, for instance, when a password has been compromised or when a license to use the servlet has expired. Revocations must be propagated, so they impose overhead. Propagation also takes time, so there may be a significant risk that the revocation will come to a given location too late to prevent authentication of a servlet that should not be authenticated. The necessary and prudent checks to see whether credentials have been revoked also impose overhead costs.
Moreover, a badly planned or implemented credential system can be worse than a simple sandbox model if the flawed credential system creates a false sense of security. Flaws in credential systems may be subtle and hard to overcome. One of the many difficult design issues that must be carefully addressed is illicit use of credentials. Unless adequate precautions are taken, for instance, a malevolent servlet can use credentials stolen or copied from a legitimate servlet to pass itself off as legitimate. Credentials must not only be difficult to forge and easy to revoke, they must also be closely tied to the servlet that is their legitimate owner. These requirements are difficult to meet without imposing overhead costs, both as administrative burdens and as extra processing and storage requirements.
The sandbox and credential models illustrate aspects of two distributed system security procedures, namely, "authentication" and "delegation." Authentication is the procedure a user goes through to establish its identity to the system, while delegation is a procedure that gives one user the security rights of another user.
In a typical sandbox model, for instance, authentication distinguishes mainly between locally loaded servlets and servlets loaded from a remote host. The server then delegates its broad rights to the locally loaded servlets, while the remote host's servlets receive only the narrow rights of a separately authenticated dispatcher instance.
In a distributed system that uses credentials for authentication, one task may lend its credentials to another, in effect delegating all its rights to that task. The delegate task may use the credentials to impersonate the lender task, that is, to be authenticated as the lender task. This form of delegation is very risky unless the delegate is fully trusted, because the set of things the lender (and now the delegate) can do is normally much wider than the set of things the lender (or the delegate) should do.
In spite of the risk, many systems routinely allow one process to temporarily assume to identity of another process, whether the lending credentials or by other means. The UNIX operating system, for instance, has long provided functions such as setuid( ) for setting the user identity, and early versions of the Novell NetWare Queue Management System ("NetWare QMS") provide a ChangeToClientRights( ) call which allows a process servicing a queue to assume the login identity of a client that placed a job in the queue.
On UNIX systems, the risk is reduced by restricting the direction of setuid( ) calls; administrators can use setuid( ) to impersonate regular users, but not vice versa. NetWare QMS reduces the risk by likewise giving administrators greater rights than other users, and also allows limits to be placed on both the set of users who can put jobs in a given queue and the job servers who can service that queue. NetWare QMS may be viewed as a generalization of the sandbox approach, in that the sandbox limits the set of users who can place servlets in the server dispatch queue to the server itself, which in turn only places locally loaded servlets in its dispatch queue. In other ways, however, NetWare QMS is more limited than the sandbox model. NetWare QMS provides neither a general capability for extending server functionality by plugging in local and remote servlets, nor a facility for executing Java bytecodes and other platform-independent executables.
A severely limited form of delegation may be performed when a parent process creates one or more child processes. In many systems, each child process normally receives the parent's security rights. However, this form of delegation requires that the delegate be a child of the delegating process. Likewise, a severely limited form of delegation may occur when a process is cloned by copying state information (or state information and code), either from one address space to another on a single computer or from one computer to another computer. However, this is even more restrictive that the parent-child delegation, since the "child" process is a clone of the parent. Migrating state information across a network link also imposes significant overhead.
Accordingly, it would be an advance to provide a more flexible approach to servlet security and delegation. In particular, it would be an advance to provide an approach to rights delegation which is more flexible and powerful than the sandbox model and known queuing methods, without incurring the overhead of the certificate model.
Such an approach to delegation in a distributed system is described and claimed below.